-
Notifications
You must be signed in to change notification settings - Fork 280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Streamline has_trait_flag behavior #2911
Streamline has_trait_flag behavior #2911
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we could use std::find_if
.
Could also be handy, not sure if it's used in the code at present. |
It needs a conversion to proper id'd object, with generic factory and all. Having the flags be strings is not very maintainable. EDIT: Maybe it's possible to reuse the flag class used for item flags |
I'm not really sure how to do that is the problem. :/ |
After this is done, trait flags will use quick |
Ah, thanks. I'll try to work on it when I get home later today, as currently getting ready to head out. |
Okay, I've committed what I've got so far, with the flag_trait files and injections into init.cpp, will tinker with this more then see when I can test it. |
Apart from what I mentioned above, it looks good. |
Ah thanks, will work on that then resume testing in a bit then, got woke up and was about to test something else in a moment. |
Let's see, still some errors currently that don't seem to make sense. Also it seems that regular flags don't have a null defined in string_id_null_ids.cpp hence the declaration in the file itself. |
They define the null flag as a constant |
Ah, I'll try and work on it when I get time, just been juggling a lot IRL lately. @.@ |
So now I've got the actual definition of trait flags working, I'm poking through and need to find which part is responsible for trait flags checking regular flags, in order to change it... |
Spotted thanks to cataclysmbnteam/Cataclysm-BN#2911
Alright, I've got the code actually checking for if a trait flag exists and confirmed it actually works. That should leave the "check that conflicting trait flags actually works" as the last step. I'm still not 100% sure how to format that. |
Co-authored-by: olanti-p <[email protected]>
Co-authored-by: olanti-p <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CV, could you compile test this again, it worked on my machine but i'd like to be extra sure
Compiled and load-tested with no issues, did the delicious people meat test too, as before it warns if you have no traits, doesn't warn if you have psychopath. Should I repeat more of the tests in the OP? |
no, i think it's good. |
Yeah, third-party mods that use mutation flags for anything need an update to define the flags they use in JSON. I had updates set aside for my mods affected by this and notified Kenan, but others will need to be made aware of it. @.@ |
* Streamline has_trait_flag behavior * Start work on it * Update type_id.h * Update the thing * Commit latest fixes * Update flag_trait.h * Commit what I have for now * style(autofix.ci): automated formatting * Update condition.cpp * And that should be the basics of the code * style(autofix.ci): automated formatting * Start up the JSON work next * Update flags_mutation.json * Update JSON_FLAGS.md * style(autofix.ci): automated formatting * Update flags_mutation.json * Update string_id_null_ids.cpp * Apply suggestions from code review Co-authored-by: Olanti <[email protected]> * Do some of the suggested things * Work on part of the requests * Add the validation thingy * refactor: extract `trait_flag_str_id` for `PRED` * refactor: remove `conflicts` usage Co-authored-by: olanti-p <[email protected]> * refactor: extract other trait flag ids Co-authored-by: olanti-p <[email protected]> * style(autofix.ci): automated formatting --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com> Co-authored-by: Olanti <[email protected]> Co-authored-by: scarf <[email protected]>
Summary
SUMMARY: Performance "Rework has_trait_flag to check mutation cache instead of all traits, overhaul with support for trait flag strings leading to IDs instead of using std::string"
Purpose of change
Back while I was working on #1486 it was brought up that
has_trait_flag
evidently taxes performance moreso thanhas_trait
, with this being a blocker.Since I like JSONizing hardcoded trait effects so that modders can do cool stuff with them, it would be a good idea to make
has_trait_flag
have comparable performance impact ashas_trait
. It turned out to be significantly more complicated due to how flags are (or really, aren't) handled under the hood, but the original idea is still buried in there alongside the bigger changes per Coolthulhu's suggestion. In short, mutation flags had to be defined as a whole separate thing that the code can look up in more efficiency ways than the usual method that strings are grabbed for all other flag checks.Describe the solution
JSON Changes:
mutation_flag
entry for every trait flag currently used by the code. Also went ahead and defined themycus
flag used for dialogue screening of Marloss mutations and the flags used only by cosmetic hair traits.NON_TRESH
from the regular flags.json, being the only trait flag with an entry there.C++ Changes:
trait_flag_str_id
instead of mere strings.Character::practice
so that the checks for the pred trait flags are formatted to work with the new trait flags, doing the same withCharacter::apply_skill_boost
now with removing the self-contained definitions of flags that probably should be moved to the top of the file if they're going to be kept (and might still be, as per alternatives section).Character::mod_thirst
,Character::mod_rad
, andCharacter::set_highest_cat_level
were all also updated so that uses ofhas_trait_flag
in them all asked fortrait_flag_str_id
instead of a raw string.has_trait_flag
to ask fortrait_flag_id
instead ofstd::string
.set_has_trait_flag
check so that it feedstrait_flag_to_check
tohas_trait_flag
as a trait flag string instead of just a string.Character::will_eat
so that its use of a trait flag check uses a trait flag string instead of a string.std::string
. Per Coolthulhu's advice in this PR and on the discord, this establishes the JSON to be checked and checking that the code is using trait flags that actually exist in the JSON. This is what definestrait_flag_id
as IDs for trait flag checks in the code to use, andtrait_flag_str_id
as strings for trait flags that can be checked and handled in whatever ways it needs that just being fedstd::string
wholesale won't allow.DynamicDataLoader::initialize
to tell it thatmutation_flag
is a type of JSON entry that exists, and added relevant checks for flag_trait stuff toDynamicDataLoader::unload_data
,DynamicDataLoader::finalize_loaded_data
, andDynamicDataLoader::check_consistency
.trait_flag_str_id
instead ofstd::string
.enzlave_actor::use
.spell::spell_fail
.Character::roll_bash_damage
,Character::roll_cut_damage
, andCharacter::roll_stab_damage
.mdeath::guilt
.Character::has_trait_flag
so it asks for atrait_flag_id
instead ofstd::string
. In addition, as per the original focus of this PR, it's set to checkcached_mutations
instead of callingget_mutations
, with the expectation that this will have some improvement in performance should more uses of traitflag checks be added to the code.trait_flag_str_id
instead ofstd::string
when they ask for flags.mutation_branch::load
so that loading mutation flags correctly tries to read trait flag strings instead of usingstring_reader
. For now I've kept it so the JSON in mutations still saysflags
instead of changing it, to save some editing of mutation JSON and so modders don't have any mods that add mutations with flags instantly broken by this PR.json_trait_flag
.Documentation Changes:
Describe alternatives you've considered
trait_flag_str_id
multiple times per file. For now I've kept usage in the files consistent with original usage, this could be done in this PR or a followup, whatever would be preferred.flags
. This would help reduce confusion about the fact that mutation flags are a whole different type of JSON thing from other flags, but as noted earlier it would increase the amount of minor JSON edits and modders would have to update any mutations they have that use flags. With this, all the work is already done on our end and any flags used by the code will still behave the same for those modders.SAPIOVORE
flag and changing whatever trait flag checks we need to to make it actually have an in-repo use in mutation JSON. No idea what we'd even what it to do separately from Cannibal though.Testing
NO_THIRST
andNO_RADIATION
flags to a trait, tested sitting around in a HWS for a while both with and without that trait, confirming that both work as intended.NON_THRESH
flag to it and confirmed that it no longer counted as adding to mutation category strength.has_trait flag
still works.UNARMED_BONUS
flag is removed from Rat Claws.Dumb thing: Culler and Hunter reduce the morale penalty from enzlaving a zombie, and Apex Predator eliminates it outright, but
PRED3
is in a derpy weird spot where it increases your tolerance for being willing to start mutilating a zombie, but does nothing for how massive a penalty you take from it like its preceding traits do.I don't actually know how to confirm how much better this performs than using
get_mutation
...Additional context